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(54) GARBAGE COLLECTION SYSTEM 



(57) The object of the present invention is to provide 
a garbage collection (GC) system that suppresses waste- 
ful increase in CPU time requiredfor GC, without stopping 
all AP threads for an excessively long amount of time. 
The garbage collection system frees memory areas cor- 
responding to objects that are no longer required in an 
execution procedure of an object-oriented program com- 
posed of a plurality of threads, and includes: a selection 
unit operable to select the threads one at a time; an ex- 
amination unit operable to execute examination process- 
ing with respect to the selected thread, the examination 
processing including procedures of stopping execution 
of the thread, finding an object that is accessible from 
the thread by referring to an object pointer, managing the 
found object as a non-freeing target, and resuming exe- 
cution of the thread; a detection unit operable to, when 
having detected, after the selection unit has commenced 
selecting, that an object pointer has been processed as 
a processing target by a currently-executed thread, man- 
age an object indicated by the processing target object 
pointer, as a non-freeing target; and a freeing unit oper- 
able to, after the examination processing has been com- 
pleted with respect to all of the threads, free memory 
areas that correspond to objects other than the objects 



Europaisches Patentamt 
(19) /ill] European Patent Office 

Office europeen des brevets 



that are managed as non-freeing targets. 



F\G3 




SEARCH TOR AP 




RETREVE LOW HBOR1TY AP 
THREADS FROM AMONG 


THREADS WTTH LOW 




PWORTTY LEVEL 




SEARCH RESULT AP THREADS 






1 S35 




Printed by Jouve, 75001 PARIS (FR) 



1 



EP 1 659 496 A1 



2 



Description 
Technical Field 

[0001] The present invention relates to garbage col- 
lection (GC) in a memory used by an application program 
(AP). 

Background Art 

[0002] In some conventional object oriented program- 
ming languages, freeing of memory area corresponding 
to objects (also called "object instance") that are no long- 
er required after being used by an AP is the responsibility 
of the execution environment Employing such a method 
relieves the creator of the AP from being concerned with 
allocation and freeing of memory area. One example of 
an object oriented programming language is Java. Note 
that Java is a trademark of the Sun Microsystems Inc of 
the USA. 

[0003] An AP written using such a language is run on 
an execution environment that includes a garbage col- 
lection (GC) mechanism that automatically frees the 
memory area corresponding to objects that are no longer 
required. 

[0004] When an AP is being executed, the GC config- 
uration detects that a memory area corresponding to a 
dynamically-allocated object is not being referenced from 
anywhere, and frees the memory area so that the mem- 
ory area is in a reusable state. 
[0005] In a multithreaded AP, each thread corre- 
sponds to a stack area, and, in a operation process, 
stores data in the stack area, refers to stored data, and 
generates an object. Ordinarily when an object is gener- 
ated, a pointerf or the object (hereinafter called an "object 
pointer") is stored in the stack area. The object pointer 
is data indicating the location of the object in the memory. 
The object is accessed from the thread by referring to 
the object pointer. Furthermore, ordinarily, an object 
pointer to another object is also stored in the object 
[0006] All objects that are being referenced by the AP 
at a particular point in time can be reached either directly 
from an object pointer included in one of the stack areas 
corresponding to the threads, or via the object pointers 
in one or more objects. 

[0007] In response to this, the GC mechanism essen- 
tially determines that a memory area corresponding to 
an obj ectthat is no longer reachable from an object point- 
er in a stack at a particular point in time is no longer 
required, and frees the memory area. 
[0008] One conventional GC method is mark-and- 
sweep. The mark-and-sweep method marks all objects 
that can be reached from an object pointer, then scans 
all objects, and frees memory area corresponding to ob- 
jects that are not marked. 

[0009] When this mark-and-sweep GC is performed 
during execution of a multithreaded AP, priority may be 
given to prompt performance of GC. To do so, marking 



of all objects that can be reached from an object pointer 
in the stack corresponding to each thread is performed 
after simply stopping all threads, then the stop on ail the 
threads is released, and objects that are not marked are 
5 freed. However, the following problem occurs in such a 
case. 

[0010] Specifically, there is a possibility that all the 
threads of the AP will be stopped for a relatively long 
time. During this time, the computer does not react to 
io user operations or the like, and, as one example, the 
display contents on the display of the computer may re- 
main the same. This causes confusion for the user. 
[0011] One method for solving this problem is dis- 
closed in Japanese Patent No. 3027845. This method 

15 proposes GC using mark-and-sweep that is executed 
without stopping a multithreaded AP at all. 
[0012] With this method, first processing is performed 
for marking all.objects that can be reached from an object 
that is a root node and all objects that can be reached 

20 from object pointers in the stack area for each thread. 
Second processing is then performed for, when an object 
pointer to an object has moved due to an operation of a 
thread of an AP (hereinafter called an "AP thread") during 
the first processing, stacking data expressing that object 

25 in a mark stack area, and when the marking processing 
is complete, further marking all objects that can be 
reached from the mark stack. Finally, memory areas cor- 
responding to unmarked objects are freed. 
[0013] However, with this method that marks without 

30 stopping the AP, there is a possibility that, since data in 
the stack area changes due to AP thread operation, part 
of the processing for marking objects that can be reached 
from the object pointer in the stack area will be wasteful. 
[0014] Take, for example, the following case. While a 

35 thread for garbage collecting is executing processing 
(here, called "processing A") for detecting an object point- 
er (here, called "object pointer A") in one stack area of 
the AP and marking objects that are reachable from the 
object pointer A, the AP thread corresponding to the stack 

40 area copies the object pointer A or the one or more object 
pointers in the objects, and newly stores the copied object 
pointer A or object pointers in a stack area. Here, the 
thread that performs GC will, after ending the processing 
A, either perform processing that duplicates the process- 
es ing A in part, or perform check processing to prevent 
duplicate processing. Either processing will be wasteful. 
This wasteful processing leads to an unnecessary in- 
crease in the CPU time required from start to completion 
of GC, and consequently lowers the usage efficiency of 

so the CPU. 

Disclosure of the Invention 

[001 5] The present invention was conceived in view of 
55 the stated problem, and has an object of providing a gar- 
bage collection (GC) system that uses a GC method 
which prevents the time for which all threads of an AP 
are stepped from being excessively long, and which sup- 



3 



EP 1 659 498 A1 



4 



presses, to an extent, wasteful increases in CPU time 
taken from the start to completion of GC. 
[001 6] In order to achieve the stated object, the present 
invention is a garbage collection system that frees mem- 
ory areas corresponding to objects that are no longer 
required in an execution procedure of an object-oriented 
program composed of a plurality of threads, the garbage 
collection system including: a selection unit operable to 
select the threads one at a time; an examination unit op- 
erable to execute examination processing with respect 
to the selected thread, the examination processing in- 
cluding procedures of stopping execution of the thread, 
finding an object that is accessible from the thread by 
referring to an object pointer, managing the found object 
as a non-freeing target, and resuming execution of the 
thread; a detection unit operable to, when having detect- 
ed, after the selection unit has commenced selecting, 
that an object pointer has been processed as a process- 
ing target by a currently-executed thread, manage an 
object indicated by the processing target object pointer, 
as a non-freeing target; and a freeing unit operable to, 
after the examination processing has been completed 
with respect to all of the threads, free memory areas that 
correspond to objects otherthan the objects that are man- 
aged as non-freeing targets. 

[0017] Here, an object pointer being processed as a 
processing target by a thread means that in the process- 
ing procedure of the thread by the CPU, an instruction is 
executed that processes the object pointer as a process- 
ing target 

[0018] Furthermore, managing an obj ect as a non- 
freeing target denotes the realization of marking by using 
a method such as that described later that moves the 
object pointer from a from table to a to table. 
[0019] According to the stated structure, an AP thread 
is stopped in the procedure for designating non-freeing 
targets that are objects that can be reached from the AP 
thread via an object pointer which is in the stack or is in 
an object. This avoids a situation in which operation of 
the AP thread causes data in the stack area to change, 
and therefore prevents the risk of marking processing 
performed during the procedure becoming wasteful. This 
prevents lowering of the CPU usage efficiency. 
[0020] Furthermore, according to the stated structure, 
since not all AP threads are stopped to perform marking 
processing, the time for which all threads of the AP are 
stopped can be prevented from being excessively long. 
Note that while changes may occur in the state of refer- 
encing to objects because not all AP threads are stopped, 
these changes are dealt with by monitoring whether ob- 
ject pointers have been processing targets of currently- 
executed threads. Therefore, objects that are accessible 
from any of the threads are always managed as non- 
freeing targets. 

[0021] Furthermore, the detection unit may perform 
the detection only when the currently-executed thread 
has not yet been subject to examination processing, and 
the detection unit may include: a finding sub-unit opera- 



ble to, when having performed the detection, store, to a 
working memory area that corresponds to the currently- 
executed thread, the processing target object pointer and 
an object pointer in an object that can be reached from 

5 the processing target object pointer; and a management 
sub-unit operable to, while execution of a thread is being 
stopped by the examination unit, manage, as a non-free- 
ing target, an object that can be reached from the object 
pointer in the working memory area corresponding to the 

io thread. 

[0022] According to the stated structure, only while the 
thread is the target of reference processing described 
later, in other words, only while the thread is a target of 
processingthatcorrespondsto marking objects indicated 

15 by object pointers stored in the stack or the like that cor- 
responds to the thread, processing is performed for de- 
tecting that the object pointer was a processing target of 
the thread during execution by the interpreter, and storing 
the obj ect pointer in the working memory, in other words, 

20 storing the object pointer in the memory area of the object 
reference information. Therefore, after the thread has 
been a target of reference processing, the thread can 
operate more quickly because the thread is not subject 
to detection during execution by the interpreter. 

25 [0023] Furthermore, the examination processing may 
be processing for, when an object indicated by an object 
pointer in a stack corresponding to the selected thread 
is found to be accessible, repeatedly performing a pro- 
cedure of, only when both (a) the accessible object is not 

30 already being managed as a non-freeing target and (b) 
an obj ect pointer exists in the accessible object, further 
finding that an object indicated by the object pointer in 
the accessible object is accessible, the selection unit 
may, after a first selection, further perform selection if, 

35 afterthe examination processing has been performed by 
the examination unit, any threads out of the plurality of 
threads remain that have not been subject to the exam- 
ination processing, and the selection unit may refer to 
information about the threads, and makes the selection 

40 based one or more predetermined thread selection con- 
ditions. 

[0024] The stated structu re prevents objects that come 
under objects managed as non-freeing targets frombe- 
ingmade targets of for detection in duplicate. Further- 

45 more, according to this structure which avoids duplicate 
detection, the possibility is high that the time for refer- 
encing processing with respect to threads that aresubject 
to reference processing later will be shorter than for 
threads that are subject to reference processing earlier. 

50 Therefore, by p re-determining thread selection condi- 
tions in view of the response performance required by 
each thread, control can be performed so that, to an ex- 
tent, each thread is executed exhibiting an appropriate 
response performance. 

55 [0025] Furthermore, the thread selection conditions 
may include a condition indicating that any threads 
whose thread state is a wait state are to be selected be- 
fore any threads whose thread state is a state other than 
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the wait state, and if a thread whose thread state is the 
wait state exists when making the selection, the selection 
unit may select the thread whose state is the wait state. 
[0026] According to the stated structure, the thread 
that is stopped is a thread in the wait state. This prevents 
adverse affects on the AP thread currently operating. 
[0027] Furthermore, the thread selection conditions 
may include a condition indicating that any threads 
whose th read priority level is low are to be selected before 
any threads whose thread priority level is high. 
[0028] According to the stated structure, lowering of 
execution performance can be prevented to an extent 
because the possibility is high that reference processing 
for threads with a high thread priority will be performed 
in a relatively short amount of time. 
[0029] Furthermore, the thread selection conditions 
may include a condition indicating that any threads 
whose corresponding stack size is small are to be se- 
lected before any threads whose corresponding stack 
size is large. 

[0030] The stated structure takes of advantage of the 
tendency for the time required for reference processing 
to be shorter, the smaller the effective range is of a stack 
that stores an object pointerto an object that is accessible 
from a thread. This structure achieves an effect of being 
able, to an extent, to make the time for which the threads 
are stopped even between threads, and avoids, to an 
extent, a situation in which the response performance of 
a particular thread is especially bad compared to other 
threads. 

[0031] Furthermore, the garbage collection system- 
may further include a memory management mechanism 
that manages memory with use of a memory manage- 
ment unit (MMU), wherein each time an object is to be 
generated, a memory area corresponding to the object 
is allocated by the memory management mechanism, 
and the freeing unit frees the memory areas via the mem- 
ory management mechanism. 

[0032] According to the stated structure, memory are- 
as are allocated to objects in the same way as for program 
data and the like written in a language such as C lan- 
guage, by the memory management mechanism that us- 
es an MMU. Since it is not necessary to allocate a heap 
area before generating objects, this structure is advan- 
tageous compared with a structure in which control is 
performed so as to separately manage an unnecessarily 
large heap area and allocate part of the heap area as a 
memory area for an object Furthermore, this structure 
is advantageous in that memory compaction of a heap 
area is unnecessary. 

Brief Description of the Drawings 

[0033] 

FIG. 1 is a functional block diagram of a GC system 
of a first embodiment of the present invention; 
FIG. 2 shows an example of the relationship between 



objects and object pointers; 
FIG. 3 shows a from table and a to table; 
FIG. 4A shows the state of the from table before ref- 
erence processing; 
s FIG. 4B shows the state of the from table and the to 
table after reference processing; 
FIG. 5 shows thread information, a stack, and object 
reference information; 

FIG. 6 shows the relationship between reference 
10 processing and the state of AP threads; 

FIG. 7 shows the contents of thread selection con- 
ditions; 

FIG. 8 is a flowchart showing GC control processing; 
FIG. 9 is a flowchart showing target thread determi- 
'5 nation processing; 

FIG. 10 is a flowchart showing shared object refer- 
ence processing; 

FIG. 1 1 is a flowchart showing target thread refer- 
ence processing; 
20 FIG. 12 is a flowchart showing reference processing; 
FIG. 1 3 is a flowchart showing instruction execution 
processing; 

FIG. 14 is flowchart showing object chain tracing 
processing; 

25 FIG. 1 5 is a functional block diagram of a GC system 
of a second embodiment of the present invention; 
FIG. 16 shows thread information and a stack; 
FIG. 1 7 is af lowchart showing GC control processing 
of the second embodiment; 

30 FIG. 1 8 is a flowchart showing instruction execution- 
processing of the second embodiment; and 
FIG. 1 9 shows Java objects managed by a conven- 
tional Java execution environment, and arrange- 
ment in a memory of the Java obj ects and data of 

35 a C language program. 

Best Mode for Carrying Out the Invention 
<1. First Embodiment 

40 

[0034] The following describes a garbage collection 
(GC) system of the first embodiment of the present in- 
vention with reference to the drawings. 

45 <1-1. Structure> 

[0035] FIG. 1 is a functional block diagram of the GC 
system of the first embodiment of the present invention. 
[0036] A GC system 1 0 is realized in a computer that 

so includes a CPU, a memory, and so on, by the CPU ex- 
ecuting control programs stored in the memory. The GC 
system 1 0 includes a general operating system (OS) that 
performs multithreaded control, and a so-called virtual 
machine, and is provided as an execution environment 

55 for application programs created in languages such as 
Java 

[0037] The GC system 1 0, as shown in FIG. 1 , is com- 
posed of an interpreter 1 00, an object management unit 
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200, a thread management unit 300, and a GC unit 400. 
[0038] Here, the interpreter 1 00 is essentially an inter- 
preter that has a function of executing APs, and includes 
an instruction execution unit 11 0 and an object reference 
detection unit 120. 

[0039] The obj ect management unit 200 has a function 
of managing obj ects, and includes an object manage- 
ment information storage unit 21 0, an obj ect generation 
unit 230, and a table switching unit 240. The object man- 
agement information storage unit 21 0 is a memory area 
that corresponds to a from table 221 , a to table 222, and 
so on. 

[0040] Note thatthe from table 221 is provided for stor- 
ing all object pointers corresponding to all objects that 
exist before GC commences. The to table 222 is used to 
store object pointers of objects that have been marked 
according to mark-and-sweep. These tables are de- 
scribed in detail later. 

[0041] The thread management unit 300 has a function 
of realizing multithreaded control and managing threads. 
The thread management unit 300 includes a thread con- 
trol unit 31 0, and memory areas that correspond to sep- 
arate thread information 320, object reference informa- 
tion 330, and a stack 340 for each AP thread. 
[0042] Note that the thread information 320 includes a 
GC flag for each AP thread that is set ON at the start of 
overall GC processing and then set to OFF when refer- 
ence processing with respect to the corresponding AP 
thread has ended. The reference processing is process- 
ing for marking objects, and is mainly for moving, from 
the from table to the to table, object pointers that are 
identical in content to object pointers stored in stacks and 
so on for the purpose of referencing objects. 
[0043] The GC unit 400 is essentially a garbage col- 
lector, and includes a GC control unit 410, a thread se- 
lection condition storage unit 420, a reference processing 
unit 430, and a freeing unit 440. GC that is performed 
primarily by the GC unit 400 essentially uses the mark- 
and-sweep method, and successively selects AP th reads 
as a reference processing target, stops the selected AP 
thread, and after performing reference processing, re- 
moves the stop from the thread. 
[0044] The instruction execution unit 1 1 0 of the inter- 
preter 1 00 has a function of consecutively interpreting an 
instruction stream that makes up an AP thread, and when 
an instruction is an object generate instruction, having 
the object generation unit 230 generate an obj ect 
[0045] The object reference detection unit 120 has a 
function of, when an instruction in a thread executed by 
the instruction execution unit 1 1 0 is an instruction that 
processes the object pointer of an object a processing 
target, storing the object pointer in the memory area of 
the object reference information 330. Note that the object 
reference detection unit 120 performs this function only 
when the GC flag is ON. 

[0046] The object generation unit 230 of the object 
management unit 200 has a function of generating an 
object in the memory by referring to object definition in- 



formation such as class files and making a request to a 
conventional OS memory management mechanism for 
allocation of a memory area of a size necessary for the 
object Note that the GC system 10 includes a conven- 
5 tional OS memory management mechanism that uses a 
memory management unit (MMU) to associate physical 
memory with logical address spaces, and manage allo- 
cation and freeing of the memory. This memory manage- 
ment mechanism has a function of, when a request is 
10 received for a memory area of a particular size, managing 
a memory area of the requested size, from among un- 
used area of the logical address space, as an assigned 
memory area, and returning the top address of the as- 
signed memory area. Consequently, the object genera- 
's tion unit 230 generates an object in the memory by as- 
signing an area in the logical address space correspond- 
ing to the object through the memory management mech- 
anism. 

[0047] Note that in addition to AP objects created in a 
20 language such as Java and executed by the interpreter 
1 00, the logical address space also has arrayed therein 
program data that is executed under the direct control of 
a conventional OS, without going through the interpreter 
1 00. In other words, data of programs that have already 
25 been put in an executable format by a compiler or the 
like. This data is referred to as "native data" hereinafter. 
Programs that are in a format executable without going 
through the interpreter 100 are allocated memory area 
via the conventional OS memory management mecha- 
30 nism for arraying native data. Allocation of the memory 
area for objects generated by the object generation unit 
230 is performed in the same manner as arranging native 
data in the memory area. 

[0048] Such native data and programs relating to the 
35 native data are not directly relevant to the GC operations 
that are the feature of the GC system 1 0, and therefore 
a detailed description thereof is omitted from the present 
description. 

[0049] Note that the term "AP thread" used above re- 

40 fers to a thread that is a unit of execution of an AP exe- 
cuted via the interpreter unit 100, in other words, a thread 
other than a unit of execution of a program relating to 
native data. Furthermore, the term "object" used here 
does not include native data. 

45 [0050] The table switching unit 240 has the function of 
causing an effect that is equivalent to the contents of the 
from table being instantly exchanged with the contents 
of the to table, by exchanging a pointer used to indicate 
the from table with a pointer used to indicate the to table. 

so [0051] The thread control unit 31 0 of the thread man- 
agement unit 300 performs multithreaded control, and 
serially executes threads including AP threads that make 
up an AP and GC processing threads. That is, the thread 
control unit 31 0 switches and executes threads at minute 

55 time intervals. Note thatthe thread management unit 300 
also serially executes programth reads of native data 
However, since this multithreaded control function is es- 
sentially a function in conventional OSs and the like, and 
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is not directly relevant to the GC operations that are the 
feature of the GC system 1 0, the present description fo- 
cuses primarily on processing of AP threads and GC 
threads only. 

[0052] The thread selection storage unit 420 of the GC 
unit 400 is a memory area that stores thread selection 
conditions showing conditions for selecting an AP thread 
as a target of reference processing. 
[0053] The reference processing unit 430 has the func- 
tion of performing reference processing. The freeing unit 
440 has the function of freeing objects that have not been 
marked. In other words, the freeing unit 440 frees mem- 
ory area corresponding to an object indicated by an object 
pointer that exists in the from table 221 at the end of GC. 
Freeing of the memory area is realized by designating 
the object pointer, in other words the logical address of 
the object, and making a freeing request to the conven- 
tional OS memory management mechanism that uses 
an MMU. Note that in response to the request to free the 
designated logical address, the conventional OS mem- 
ory management mechanism included in the GC system 
1 0 manages the area allocated to the in association with 
the logical address as an unused memory area that can 
be newly allocated when it is necessary to allocate mem- 
ory area. 

[0054] Furthermore, the GC control unit 410 has the 
function of executing GC control processing. Specifically, 
the GC control unit 41 0 selects one AP thread as a target 
of reference processing by referring to the thread selec- 
tion conditions. After having the thread control unit 310 
stop the selected AP thread, the GC control unit 41 0 then 
has the reference processing unit 430 perform reference 
processing based on the stack and object reference in- 
formation corresponding to the AP thread. Next, after 
having the thread control unit release the stop on selected 
AP thread, the GC control unit 410 selects the next AP 
thread. The GC control unit 410 repeats the described 
procedure until no unprocessed AP threads exist, and 
then has the freeing unit 440 free objects that have not 
been marked. 

<1.2Data> 

[0055] The following describes data treated in the GC 
system 1 0. 

[0056] FIG. 2 shows an example of the relationship 
between objects and object pointers. 
[0057] In the drawing, object pointers are expressed 
as small, filled-in circles. 

[0058] Object pointers which indicate an object, in oth- 
er words, which indicate an address location of an object 
arranged in the logical address space corresponding to 
the memory 500, may exist in either an object, a stack, 
or shared object management information 353. Here, the 
shared object management information 353 is data that 
includes an object pointer group that indicates an object 
group allocated because it is necessary in a virtual ma- 
chine as an AP execution environment 



[0059] In the example in FIG. 2, the object pointer in 
the shared object management inf ormation 353 indicates 
an object 201c. 

[0060] Furthermore, one object pointer in the stack that 
5 corresponds to an AP thread 351 indicates an object 
201 a, in other words the contents of the memory address 
of the object 201 a. The other object pointer in the stack 
that corresponds to the AP thread 351 indicates an object 
201 d. Therefore, the AP thread 351 is able to access the 
io object 201 a and the object 201 d during execution by ref- 
erencing these object pointers. 
[0061 ] Furthermore, the object pointer in the stack cor- 
responding to the AP thread 352 indicates an object 
201 b, and an object pointer that indicates an object 201 e 
15 is included as data in the object 201 b. Therefore, the AP 
thread 352 is able to access the object 201 e by tracing 
these object pointers. 

[0062] Furthermore, FIG. 2 shows that, together with 
the objects 201 a to 201 e that correspond to APs created 

20 in a language such as Java executed via the interpreter 
100, native data 501a to 501 d whose memory area is 
also allocated by the OS memory management mecha- 
nism exists in the memory 500. Areas are allocated to 
this native data 501 a to 501 d also by the memory man- 

25 agement mechanism of the OS. In other words, the ob- 
jects 201 a to 201 e are not put together into a type of heap 
area, but are assigned respective, separate areas by the 
OS memory management mechanism in the same way 
as native data. 

30 [0063] Note that although not shown in FIG. 2, thread 
information 320, a stack 340, and object reference infor- 
mation 330 are also allocated areas in the memory 500. 
Furthermore, the object reference information storage 
unit 210 corresponds to part of the memory 500. Note 

35 that the program portion of the AP executed via the in- 
terpreter 1 00 and the program portion that accesses the 
native data may be stored in a readable/writable memory 
(RAM), or in a read only memory (ROM). 
[0064] FIG. 3 shows the from table and the to table. 

40 [0065] In the object management information storage 
unit 21 0 of the memory 500, two data are as are provided 
that are for storing a sufficient number of object pointers 
or null values. A from table pointer 21 1 and a to table 
pointer 212 also exist in the object management infor- 

45 mation storage unit 21 0. The from table pointer 21 1 in- 
dicates one of the two tables, and the to table pointer 21 2 
indicates the other of the two tables. Here, the table pres- 
ently indicated by the from table pointer 21 1 is called the 
from table, and the table presently indicated by the to 

so table pointer 21 2 is called the to table. 

[0066] At the point when GC commences, the from ta- 
ble 221 stores object pointers that correspond all objects 
that exist at that time. 

[0067] Furthermore, the to table 222 stores object 
55 pointers that are moved from the from table 221 during 
reference processing. Note that when an object pointer 
is moved from the from table 221 to the to table 222, the 
contents of the memory of the location in the from table 
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221 at which the moved object was stored are made a 
null value. 

[0068] FIG. 4A and FIG. 4B show changes in the con- 
tents of the from table and the to table due to reference 
processing. FIG. 4A shows the state before reference 
processing starts, and FIG. 4B shows the state after ref- 
erence processing. 

[0069] In FIG. 4A, a from table 221 x before the start 
of reference processing includes object pointers that in- 
dicate objects objA202a, objB202b, and objC202c, re- 
spectively. Note that FIG. 4A and FIG. 46 also express 
that both objects and native data exist in the memory 500. 
[0070] When reference processing is subsequently 
performed with an AP thread 354 as a target, data having 
the same value as the object pointer included in the stack 
of the AP thread is moved from the from table to the to 
table. The result of this move is the state shown in FIG. 
4B. The place where the object pointer indicating 
objA202a existed and the place where the object pointer 
indicating objC202c existed in the from table 221 y are 
updated to null values, and the object pointer indicating 
objA202a and the object pointer indicating objC202c are 
stored in the to table 222y. 

[0071] FIG. 5 shows thread information, stacks, and 
object reference information. 

[0072] Thread information 320 is generated each time 
an AP thread is generated for that AP thread, and in- 
cludes information about that AP thread. Specifically, the 
thread information 320 includes a state 321, a priority 
level 322, a stack pointer 323, a GC start stack pointer 
324, a GC flag 325, an object reference information top 
pointer 326, and an object reference information current 
pointer 327. Note that when an AP thread is generated, 
a memory area is allocated not only in the thread infor- 
mation 320, but also in the stack 340. 
[0073] The state 321 in the thread information 320 is 
information that shows the state of the thread for the pur- 
pose of multithreaded control, and indicates either a wait 
state, a run state, or a ready state. 
[0074] The priority level 322 is information that shows 
the priority level of the thread. The priority level is set, for 
example, by a designation received from the AP when 
the thread is generated. Note that in multithreaded con- 
trol, if a high priority level thread is in the ready state, the 
high priority thread is put into a run state before lower 
priority level threads. 

[0075] The stack pointer 323 shows the end of the 
range of currently effective data in the stack relating to 
the thread. Note that in multithreaded control, when a 
thread is switched from the run state to another state, in 
other words to a stopped state, the value stored in a pre- 
determined register that has indicated the stack pointer 
until that point in time is stored in the stack pointer 323, 
and when the thread is switched to the run state, the 
value in the stack pointer 323 is set in the predetermined 
register. 

[0076] The GC start stack pointer 324 shows the end 
of the range of effective data in the stack at the time of 



starting GC. 

[0077] The GC flag 325 is set to ON at the overall start 
of GC processing, and is set to OFF when reference 
processing with respect to the AP thread has ended. 

5 [0078] The object reference information top pointer 
326 shows the head of the memory area of the object 
reference information corresponding to the AP thread, 
and is set at the time of allocating memory area during 
generation AP thread generation. 

10 [0079] Furthermore, the object reference information 
current pointer 327 is information showing a location 
where the object reference detection unit 120 is to store 
the next object pointer in the memory area of the object 
reference information corresponding to the AP thread. 

15 The object reference information current pointer 327 is 
referenced and updated by the object reference detection 
unit 120. 

[0080] FIG. 6 shows the relationship between refer- 
ence processing and the state of an AP thread. 

20 [0081] The GC thread 356 is a thread for executing 
GC by the GC control unit 41 0. The processing that the 
GC thread 356 performs as GC successively reference 
processing with respect to the AP threads. Here, an ex- 
ample is shown of reference processing being performed 

25 with respect to AP thread 355a, AP thread 355b, and AP 
thread 355c, in the stated order. 
[0082] The AP thread 355a has been subject to refer- 
ence processing, and is being executed. Here, "being 
executed" means that the thread is not in a sleep state, 

30 in other words, not in a stopped state, and continuously 
changes state instantaneously to a run state or a ready 
state, for example. 

[0083] The AP thread 355b is in a state of being subject 
to reference processing, and is stopped. Reference 
35 processing is performed by forcedly puttingthe AP thread 
into a stopped state, and referencing the stack and object 
reference information. 

[0084] The AP thread 355c is in a state of not yet having 
been subject to reference processing, and is being exe- 
40 cuted. 

[0085] FIG. 7 shows the contents of the thread selec- 
tion conditions. 

[0086] Thread selection conditions 421 is information 
that serves as a basis forjudging which AP thread to give 
45 preference to as a target of reference processing, and is 
composed of a thread state 422, a thread priority level 
423, and a stack size 424. 

[0087] The thread state 422 is information showing 
which state of AP threads are to be given preference. 
so The example in FIG. 7 shows that AP threads in the wart 
state are to be given preference over AP threads in states 
such as the run state. 

[0088] The thread priority level 423 is information 
showing whether the AP thread to be selected as the 
55 target of reference processing should be one having high 
priority level or one having low priority level. The example 
in FIG. 7 shows that AP threads having low priority level 
are selected preferentially. 
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[0089] The stack size 424 is information showing 
whether an AP thread should be selected with preference 
given to AP threads whose corresponding stack area has 
a large effective range or to AP threads whose corre- 
sponding state area has a small effective range. The ex- 
ample in FIG. 7 shows that AP threads whose corre- 
sponding stack area has a small effective range are to 
be selected preferentially. 

<1 -3. Operations> 

[0090] The following describes operations of the GC 
system 10. 

[0091] FIG. 8 is a flowchart showing GC control 
processing. 

[0092] GC control processing is performed in a fixed 
cycle based on a timer. 

[0093] The GC control unit 41 0 first switches the con- 
tents of the from table and the to table by exchanging the 
contents of the from table pointer 21 1 with the contents 
of the to table pointer 21 2 (step S1 1 ). The resulting state 
is that object pointers indicating all objects that are cur- 
rently not freed are stored in the from table. 
[0094] Next, the GC control unit 410 has the thread 
control unit 310 stop all AP threads (step S12), sets the 
GC flag 325 in the thread information for each AP thread 
to ON, and sets the current stack pointer as the GC start 
stack pointer 324 in the thread information (step S13). 
The GC control unit 41 0 then has the thread control unit 
31 0 release the stop from all the AP threads (step S1 4). 
At step S13, with respect to each AP thread, the GC 
control unit 410 further allocates a memory area for the 
object reference information, and sets an object pointer 
that indicates the top of that memory area in the object 
reference information top pointer 326 and the object ref- 
erence information current pointer 327. 
[0095] Note that the thread control unit 31 0 stops and 
releases the stop on threads in the same way as a con- 
ventional OS multithreaded control mechanism. This 
stopping of a thread is control for putting a thread into a 
stopped state, in other words, a sleep state, and this re- 
leasing of stopping of a thread is control for releasing the 
sleep state, and returning the thread to a ready state. 
[0096] After step S1 4, the GCcontrol unit41 0 performs 
shared reference processing for marking objects that can 
be reached by tracing object pointers in the shared object 
management information 353 (step S1 5). The GC control 
unit 410 determines whether or not any non-GC proc- 
essed threads, in other words AP threads that have not 
yet been selected as a target of reference processing, 
exist (step S16). Note that shared object reference 
processing is described later. 

[0097] When any non-GC processed threads are de- 
termined to exist at step S16, the GC control unit 410 
performs target thread determination processing for se- 
lecting an AP thread as the target of reference processing 
(step S17), has the thread control unit 310 stop the se- 
lected AP thread (step S1 8), executes target thread ref- 



erence processing with respect to the contents of the 
selected AP thread (step S19), sets the GC flag 325 of 
the selected AP thread to OFF (step S20), has the thread 
control unit 310 release the stop from the selected AP 

5 thread (step S21), and returns to the judgment at step 
S1 6. Note that the target thread determination process- 
ing and the target thread reference processing are de- 
scribed later. Furthermore, directly after step S20, the 
GC control unit 41 0 frees the memory area of the object 

io reference information corresponding to the target AP 
thread. 

[0098] Furthermore, when no non-GC processed 
threads are determined to exist at step S1 6, the GC con- 
trol unit 41 0 has the freeing unit 440 free objects that are 

is not marked (stepS22), and ends the processing. At step 
S22, the freeing unit 440 frees the memory areas corre- 
sponding to objects that have not been moved to the to 
table according to reference processing, in other words 
objects that are indicated by object pointers remaining in 

20 the from table. Here, freeing corresponds to the object 
generation unit 230 securing a memory area for allocat- 
ing to an object for object generation based on an OS 
memory management mechanism that uses MMU, and 
denotes freeing of the allocated memory area. Note that 

2s a memory area that has been freed is able to be newly 
assigned as a storage area for an object or native data 
[0099] FIG. 9 is a flowchart showing target thread de- 
termination processing. 

[0100] The GC control unit 410 refers to the thread 
30 selection conditions 421 in the thread selection condition 
information unit 420 to perform target thread determina- 
tion processing. 

[01 01 ] First, the GC control unit 41 0 refers to the thread 
information corresponding to each AP thread, and 

35 searches for AP threads whose state 321 is the wait state 
(step S31). The GC control unit 410 determines the 
number of threads (thread count) found as a search result 
(step S32), and if the thread count is "one", determines 
thefound AP thread to be the reference processing target 

40 thread (step S37), and ends the target thread determi- 
nation processing. 

[0102] Furthermore, if the thread count of the search 
result at step S23 is "zero", the GC control unit 410 
searches for AP threads having the lowest priority level 

45 322 (step S33), and judges whether or not the thread 
count of the search result is "one" (step S35). Further- 
more, if the thread count of the search result at step S32 
is two or more", the GC control unit 410 narrows down 
the search result by searching for the AP thread that has 

so lowest priority level 322 among the AP threads of the 
search result (step S34), and judges whether or not the 
thread count of the search result is "one" (step S35). 
[01 03] When the thread count is judged to be "one" at 
step S35, the GC control unit 410 selects the AP thread 

55 of the search result as the target thread of AP reference 
processing (step S37), and ends the target thread deter- 
mination processing. 

[0104] Furthermore, if the thread count of the search 
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result is judged not to be "one" at step S35, in other words, 
if a plurality of threads having the lowest priority level 
exist, the GC control unit 41 0 searches for the AP thread 
having the smallest stack size among the AP threads of 
the search result (step S36), determines the AP thread 
having the smallest stack size to be the target of refer- 
ence processing (step S37), and ends the target thread 
determination processing. 

[0105] FIG. 10 is a flowchart showing shared object 
reference processing. 

[01 06] The GC control unit 41 0 focuses on the top ob- 
ject pointer of the shared object management inf ormation 
353 that includes an object pointer group (step S41 ), and, 
by having the reference processing unit 430 perform ref- 
erence processing (step S42), marks all objects in the 
object group that are assigned because they are neces- 
sary in a virtual machine that operates as an AP execution 
environment 

[0107] FIG. 11 is a flowchart showing target thread ref- 
erence processing. 

[0108] The GC control unit 41 0 focuses on the location 
indicated by the GC start stack pointer 324 corresponding 
to the target thread (step S51 ), and, by having the refer- 
ence processing unit 430 perform reference processing 
(step S52), marks ail objects that can be reached from 
object pointers in the stack area. Note that since the point 
in time at which the GC control processing (see FIG. 8) 
starts and the point in time at which the target thread 
reference processing start are different, the contents of 
the location indicated by the GC start stack pointer 324 
and the contents of the subsequent locations are different 
to when GC started. However, according to the subse- 
quent step S53 and step S54, all objects that can be 
reached from object pointers that have changed accord- 
ing to operation of the target thread are marked. There- 
fore, while this may result in excessive marking, it pre- 
vents a situation in which some obj ects, despite being 
referenced, fail to be marked. 

[0109] Next, the GC control unit 410 focuses on the 

location indicated by the object reference information top 

pointer 326 (step S53), has the reference processing unit 

430 perform reference processing (step S54), and ends 

the target thread reference processing. 

[0110] FIG. 12 is a flowchart showing reference 

processing. 

[01 1 1 ] The reference processingunit 430 searches for 
an object pointer from the memory location being focused 
on (step S61 ), judges whether an object pointer has been 
detected (stepS62), and when an object pointer has been 
detected, judges whether an object pointer having the 
same value as the detected object pointer exists in the 
from table (step S64). if such as object pointer exists in 
the from table, the reference processing unit 430 copies 
the object pointer from the from table to the to table, and 
records a null value in the location at which the object 
pointer existed in thef rom table (step S66). The reference 
processing unit 430 then focuses on the top of the data 
of the object that the object pointer indicates (step S67), 



and returns to step S61 . 

[01 1 2] Fu rthermore, if it is judged at step S64 that such 
an object pointer does not exist in the from table, the 
reference processing unit 430 focuses on the next loca- 
5 tion after the location currently being focused on, since 
the object pointer has already been moved from the from 
table to the to table (step S65), and returns to step S61 . 
The combination of step S65 and step S61 realizes the 
following: successive searching for object pointers in the 
10 shared object management information 353; successive 
searching for object pointers in the stack; successive 
searching for object pointers in the object reference in- 
formation; and successive searching for object pointers 
that are data members of a particular object. 

is [0113] Furthermore, when it is judged at step S 62 that 
an object pointer was not able to be detected, the refer- 
ence processing unit 430 judges whether or not the focus 
location is within an object (step S63). Note that not being 
able to detect an object pointer means (a) if the focus 

20 location is in the shared object management information 
353, that an object pointer is unable to be detected in the 
shared object management information 353, (b) if the 
focus location is within the stack, an object pointer is un- 
able to be detected in the stack, (c) if the focus location 

25 js within the object reference information, an object point- 
er is unable to be detected in the object reference infor- 
mation, and (d) if the focus point is within an object, an 
object pointer not being able to be found in that object 
[01 1 4] When the focus location is judged to be within 

30 an object at step S63, the reference processing unit 430 
next focuses on the location that proceeded the present 
focus location before the present focus location was fo- 
cused on (step S68), and then returns to step S61. Ac- 
cording to this step S68, the reference processing unit 

35 430 focuses on the location in the object that follows the 
object pointerthat was being focused on before step S67. 
[01 15] Furthermore, when it is judged at step S63 that 
the focus location is not within an object, the reference 
processing unit 430 ends the reference processing. 

to [0116] FIG. 13 is a flowchart showing instruction exe- 
cution processing. 

[01 17] The instruction execution unit 1 1 0 of the inter- 
preter 100 performs instruction execution processing by 
successively interpreting and executing instruction de- 
45 scriptions in the program of the AP thread that is in the 
run state. 

[0118] First, the instruction execution unit 110 inter- 
prets and executes the instruction in the current execu- 
tion location of the AP thread (step S71), and the object 

50 reference detection unit 120 judges whether or not the 
GC flag 325 in the thread information corresponding to 
the AP thread is ON (step S72). If the GC flag 325 is not 
ON, the instruction execution unit 1 1 0 interprets and ex- 
ecutes the next instruction (step S71). 

55 [01 1 9] If the GC flag is judged to be ON at step S72, 
the object reference detection unit 120 judges whether 
the instruction executed by the instruction execution unit 
110 at step S71 was an instruction that processes an 
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object pointer as a processing target (step S73), and if 
not, the instruction execution unit 1 1 0 interprets and ex- 
ecutes the next instruction (step S71). Note that an in- 
struction that processes an object pointer as a processing 
target is an instruction that instructs a computation for s 
copying the object pointer in a stack to a object, or an 
instruction that instructs a computation for copying the 
object pointer in the object to another object 
[01 20] When it is judged at step S73 that the instruction 
was an instruction that processes an object pointer as a io 
processing target, the object reference detection unit 1 20 
judges whether data of the same value as the obj ect 
pointer has been stored in the obj ect reference informa- 
tion area (step S74), and if so, the instruction execution 
unit 1 1 0 interprets and executes the next instruction (step 
S71). 

[01 21 ] If ft is judged at step S74 that data of the same 
value as the object pointer has not been stored in the 
object reference information area, the object reference 
detection unit 1 20 stores the obj ect pointer at the location 20 
in the object reference information that is indicated by 
the object reference information current pointer 327 (step 

575) , focuses on the object indicated by the object point- 
er, and performs object chain trace processing (step 

576) . The instruction execution unit 1 1 0 then interprets 25 
and executes the next instruction (step S71). 

[01 22] Note that when the instruction executed at step 
S71 is an instruction for generating an object, the instruc- 
tion execution unit 110 instructs the object generation 
unit 230 to generate an object. Having received this in- 30 
struction, the object generation unit 230 generates the 
object, returns the object pointer indicated by the object 
to the AP thread, and sets a copy of the object pointer in 
the to table. 

[0123] FIG. 14 is a flowchart showing object chain 35 
trace processing. 

[01 24] The object reference detection unit 1 20 judges 
whether or not any non-focused object pointers (object 
pointers that have not yet been focused on) exist in the 
object that is being focused on (step S81 ), and when any *o 
non-focused object pointers exist, focuses on one of the 
non-focused object pointers (step S82), and stores the 
object pointer that is being focused on to the memory 
area of the object reference information (step S83). The 
object reference detection unit 120 then focuses on the 45 
object indicated by the object pointer being focused on, 
and further performs the object chain processing at steps 
S81 to S84 (step S84). Note that after storing an object 
pointer in the memory area of the obj ect reference infor- 
mation, the object reference detection unit 1 20 advances so 
the object reference information current pointer an 
amount corresponding to the size of the object pointer. 
[01 25] Furthermore, when it is judged at step S81 that 
no non-focused object pointers exist in the object being 
focused on, the object reference detection unit 1 20 ends 55 
the object chain trace processing. 
[0126] Consequently, the result of instruction execu- 
tion processing and object chain processing is that, when 



the GC flag 325 is ON, object pointers that could be 
reached from the object pointer that is the processing 
target when that object pointer was the processing target 
are stored in a memory area in the obj ect reference in- 
formation. 

[0127] Note that the processing of the above-de- 
scribed steps S72 to S76 and steps S81 to S84 is per- 
formed for the following reason. There are cases in which 
an object indicated by an object pointer becomes inac- 
cessible from a particular AP thread due to the AP thread 
executing computations that process the object pointer 
as a processing target. Specifically, the object indicated 
by the object pointer may become inaccessible from the 
AP thread when, according to AP thread operations, (a) 
the object pointer is cleared, (b) the contents of the object 
pointer are updated, or (c) the object pointer was in an 
effective range of the stack area but, due to the stack 
pointer being updated, is no longer in the effective range 
and essentially becomes inaccessible from the AP 
thread. In such cases, if the AP thread has copied the 
object pointer to a place where the object pointer is ac- 
cessible from another AP thread, the object indicated by 
the object pointer must be marked. 

<2. Second Embodiment 

[01 28] The f ol lowing describes a GC system of the sec- 
ond embodiment of the present invention with reference 
to the drawings. 

[0129] The GC system of the second embodiment is 
essentially the same as the GC system 10 of the first 
embodiment in that AP threads are successively stopped 
and subject to reference processing. However, the dif- 
ference between the two is that the GC system of the 
second embodiment does not have object reference in- 
formation and a GC flag for each AP thread, but instead 
has one set of object reference information and one GC 
flag for the system as a whole. A further difference is that 
the GC system of the present embodiment reduces the 
content of the thread information to an extent required 
for general multithreaded control. 
[01 30] FIG. 1 5 is a functional block drawing of the GC 
system of the second embodiment of the present inven- 
tion. 

[0131] Structural components of the GC system 20 
shown in FIG. 1 5 that are the same as structural compo- 
nents of the GC system 1 0 of the first embodiment have 
the same numbering thereas. The present description 
focuses on the compositional elements that are unique 
to the GC system 20. Note that any characteristics of the 
GC system not described here should be considered to 
be the same as the GC system 1 0. 
[01 32] The GC system 20, as shown in FIG. 1 5, is com- 
posed of an interpreter 1 1 00, an object management unit 
200, a thread management unit 1300, and a GC unit 
1400. 

[0133] Here, the interpreter 1 100 is essentially an in- 
terpreter that has a function of executingAPs, and in- 
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eludes the instruction execution unit 1 1 0 and an object 
reference detection unit 1120. 
[01 34] The thread management unit 1 300 has a func- 
tion of realizing multithreaded control and managing 
threads. The thread management unit 1 300 includes the s 
thread control unit 310 and memory areas that corre- 
spond, for each AP thread, to thread information 1320 
and a stack 340. Note that the thread information 1320, 
as shown in FIG. 1 6, includes a state 321 , a priority level 
322, and a stack pointer 323. 10 
[01 35] The GC unit 1 400 is essentially a garbage col- 
lector, and includes a GC control unit 1 41 0, a thread se- 
lection condition storage unit 420, a reference processing 
unit 1 430, af reeing unit 440, object reference information 
1 450, and a memory area that corresponds to object ref- is 
erence information 1450 and a GC flag 1460. 
[0136] The object reference detection unit 120 of the 
interpreter 1 1 00 has a function of, only when the GC flag 
1460 is ON, and when an instruction of an AP thread 
executed by the instruction execution unit 1 1 0 is an in- 20 
struction that processes an object pointer of an object as 
a processing target, storing the object pointer in the mem- 
ory area of the object reference information 1450. 
[0137] GC that is performed primarily by the GC unit 
400 essentially uses the mark-and-sweep method to sue- 25 
cessivety select AP threads as a reference processing 
target, stop the selected AP thread, and after performing 
reference processing, remove the stop from the thread. 
[0138] The reference processing unit 1430 of the GC 
unit 1400 has the function of performing reference 30 
processing by referring to the stack and the object refer- 
ence information 1450. The object reference information 
1450 is information whose contents include object point- 
ers, in the same way as the object reference information 
of the GC system 10, but does not exist separately for 35 
each AP thread. Stored in the memory area of the object 
reference information is all object pointers that have been 
a processing target of an instruction by the object refer- 
ence detection unit 1 120 by AP threads. Note that the 
thread information 1 320, the stack 340, the object refer- 40 
ence information 1450, and the GCflag 1460 are stored 
in the same way as objects and native data in the memory 
that includes the object management information storage 
unit 210. 

[0139] Furthermore, the GC control unit 1410 has the 45 
function of execution GC control processing shown in 
FIG. 17. 

[0140] FIG. 17 is a flowchart showing GC control 
processing of the second embodiment. Note that the 
steps in the flowchart that are the same as steps in the so 
GC control processing of the first embodiment have the 
same numbering as in FIG. 8. 
[0141] This GC control processing is performed in a 
fixed cycle based on a timer. 

[01 42] The GC control unit 1 41 0 first switches the con- 55 
tents of the from table and the to table by exchanging the 
contents of the from table pointer 21 1 with the contents 
of the to table pointer 212 (step S1 1), and sets the GC 



flag 1460 to ON (step S1 1 1). 

[0143] After step S1 1 1, the GC control unit 1410 per- 
forms shared reference processing for marking objects 
that canbe reached by tracing object pointers in the 
shared object management information 353 (step S15). 
The GC control unit 41 0 determines whether or not any 
non-GC processed threads, in other words AP threads 
that have not been selected as a target of reference 
processing, exist (step S16). 

[0144] When any non-GC processed threads are de- 
termined to exist at step at step S1 6, the GC control unit 
41 0 performs target thread determination processing for 
selecting an AP thread as the target of reference process- 
ing (step S17), has the thread control unit 310 stop the 
selected AP thread (step S18), focuses on the location 
of the stack pointer corresponding to the selected AP 
thread (step S112), has the reference processing unit 
1430 execute reference processing (see FIG. 12) (step 
S113), has the thread control unit 310 release the stop 
from the selected AP thread (step S21), and returns to 
the judgment at step S1 6. 

[0145] Furthermore, when no non-GC processed 
threads are determined to exist at step S1 6, the GC con- 
trol unit 410 has the thread control unit 310 stop all AP 
threads (step S1 14), focuses on the top location of the 
memory area of the object reference information (step 
S1 15), has the reference processing unit 1430 execute 
reference processing (step S1 1 6), sets the GCflag 1460 
to OFF (step S117), has the thread control unit 310 re- 
move the stop from all AP threads (step S1 1 8), has the 
freeing unit 440 free objects that are not marked (step 
S22), and ends the GC control processing. 
[01 46] Here, a simple description of the instruction ex- 
ecution processing performed by the interpreter 1 100 is 
given. 

[01 47] FIG. 1 8 is a flowchart showing instruction exe- 
cution processing in the second embodiment 
[01 48] As can be seen in the drawing, this instruction 
execution processing is essentially equivalent to the in- 
struction execution processing shown in FIG. 1 3 with step 
S76 removed. 

[0149] First, the instruction execution unit 110 inter- 
prets and executes the instruction of the current execu- 
tion location of the AP thread (step S71), and the object 
reference detection unit 1 120 judges whether or not the 
GC flag 1 460 is ON (step S72). If the GC flag 325 is not 
ON, the instruction execution unit 1 1 0 interprets and ex- 
ecutes the next instruction (step S71). 
[01 50] If the GC flag is judged to be ON at step S72, 
the object reference detection unit 120 judges whether 
the instruction executed by the instruction execution unit 
1 1 0 at step S71 was an instruction that processes an 
object pointer as a processing target (step S73), and if 
not, the instruction execution unit 1 10 interprets and ex- 
ecutes the next instruction (step S71). 
[01 51 ] When it is judged at step S73 that the instruction 
was an instruction that processes an object pointer as a 
processing target, the object reference detection unit 1 20 
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judges whether data of the same value as the obj ect 
pointer has been stored in the obj ect reference informa- 
tion area (step S74), and if so, the instruction execution 
unit 1 1 0 interprets and executes the next instruction (step 
S71). 5 
[01 52] if it is judged at step S74 that data of the same 
value as the object pointer has not been stored in the 
object reference information memory area, the object ref- 
erence detection unit 1 20 stores the object pointer in the 
object reference information (step S75), and the instruc- 10 
tion execution unit 110 interprets and executes the next 
instruction (step S71). 

[01 53] In this way the GC control unit 1 41 0 selects one 
AP thread as a target of reference processing by referring 
to the thread selection conditions, and after having the is 
thread control unit 31 0 stop the selected thread, has the 
reference processing unit 1430 perform reference 
processing based on the stack corresponding to the AP 
thread. Next, after having the thread control unit 31 0 re- 
move the stop from the selectedAP thread, the GC control 20 
unit 1410 repeats the described procedure until no un- 
processed AP threads exist Then the GC control unit 
1410 has the thread control unit 310 release the stop 
from all AP threads, has the reference processing unit 
1 430 perform reference processing based on the object 25 
reference information, has the thread control unit 310 
remove the stop from all AP threads, and has the freeing 
unit 410 free all objects that are not marked. 

<3. Observations> so 

[0154] The following gives a brief description of the 
differences between objects managed by the described 
GC system of the present invention, and objects in a con- 
ventional garbage collector in a Java execution environ- 3s 
ment or the like. 

[01 55] The GC system of the present invention shown 
in the first and second embodiments, when executing an 
AP created with an object-oriented language such as 
Java that relieves programmers from being concerned 
with freeing of allocated memory, performs allocation of 
memory at the time of generating an object and freeing 
the memory corresponding to that object through a con- 
ventional OS memory management mechanism that us- 
es an MMU. This means that memory areas assigned 45 
for objects exist together in the logical address space 
with memory areas assigned for native data, in other 
words, data of programs created with other languages 
such as C language. FIG. 3 expresses this concept of 
co-existence. so 
[01 56] In contrast, the state of Java obj ects managed 
by a conventional Java execution environment and data 
of, in this instance, a C language program (hereinafter 
called "C data") in a memory is shown in FIG. 19. 
[01 57] As shown in FIG. 1 9, C language programs 953 55 
and 954 secure memory areas for C data 921 and 922 
in a random access memory (RAM) 900 via an OS mem- 
ory management mechanism. 



[0158] Furthermore, Java objects 91 1 to 91 3 generat- 
ed from the Java programs 951 and 952 are allocated to 
a heap area 910, and management of array within the 
heap area 950 is performed not by the OS, but by the 
Java execution environment that includes a garbage col- 
lector 950. For this reason, the Java execution environ- 
ment first secures a heap area through the OS memory 
management mechanism, and then when generating the 
object, allocates one area within the heap area to the 
object This heap area reduces the amount of memory 
that can be used for programs of other languages. 
[01 59] Furthermore, when freeing an object, the Java 
execution environment manages area allocated to the 
object in the heap area as an unused area that can be 
newly allocated to an object. However, it is necessary to 
perform memory compaction in order to connect all un- 
used areas in the heap area as required. 
[01 60] Note that in this respect, the GC system of the 
present invention as shown in the first and second em- 
bodiments does not perform heap area allocation or man- 
agement, but performs memory allocation for objects di- 
rectly through the conventional OS memory manage- 
ment mechanism. Therefore, memory compaction in a 
heap area is, naturally, unnecessary. 

<4. Additional Remarks> 

[0161] Although the GC system of the present inven- 
tion has been described based on the first and second 
embodiments, the present invention is not limited to these 
embodiments. The following describes some possible 
modifications. 

(1) Although the thread selection conditions are de- 
scribed as including three conditions, specifically, 
thread state, priority level and stack size, which are 
given priority in the stated order, the number of con- 
ditions and the order in which they are applied are 
not limited to this example. For example, selection 
may be made giving priority to threads with a high 
priority level, or to threads with a large stack size. 
However it should be noted that selecting an AP 
thread in a wait state for the reference processing 
target as described in the embodiments will adverse- 
ly effect the AP currently operating. Furthermore, the 
time required to perform reference processing (see 
FIG. 12) with respect to AP threads according to a 
reference processing algorithm is shorter for AP 
threads for which reference processing is performed 
later than for AP threads for which reference 
processing is performed earlier. Therefore, by se- 
lecting low priority threads as reference processing 
targets earlier as shown in the embodiments, the 
time for which high-priority AP threads that require 
immediate response are stopped canbe reduced. 
Furthermore, for the same reason, since the time 
required for reference processing is greater for larger 
stack sizes, by performing reference processing in 
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order of corresponding stack size starting from the 
smallest corresponding stack size, the time for which 
AP threads are stopped can be distributed evenly to 
an extent between AP threads of the same priority 
level. 5 

(2) GC control processing is not limited to being per- 
formed in a fixed cycle based on a timer as described 
in the embodiments. Instead, GC control processing 
may be performed when the amount of memory al- 
locable to APs falls below a predetermined amount. 10 

(3) The memory area of the obj ect reference 
processing described in the embodiments may be a 
memory area expressed by a contiguous physical 
address. Alternatively, a memory area of a set 
amount may be additionally allocated when neces- is 
sary at the time of storing an obj ect pointer, and the 
allocated segmentedmemory areas may be treated 

as a continuous memory area in terms of logical ad- 
dress. 

(4) In the GC system described in the first embodi- 20 
ment, when an obj ect pointer is the processing target 

in the instruction execution processing by the inter- 
preter, and if the GC flag is ON, by performing 
processing to store the object pointer in the memory 
area of the object reference information, and omit- 25 
ting, from the instruction execution processing, ref- 
erence processi ng for moving data of the same val ue 
as the object pointer from the from table, the speed 
of the instruction execution by the interpreter is main- 
tained. However, reference processingmaybe per- 30 
formed during the instruction execution processing. 

(5) In the embodiments, pointers to objects that can 
be reached from object pointers in the shared object 
management information are moved from the from 
table to me to table according to reference process- 35 
ing. However, it is not necessary to perform refer- 
ence processing. It is sufficient for objects that are 
managed according to the shared object manage- 
ment information to be excluded from being a target 

of freeing by the freeing unit *o 

(6) The GC system shown in the embodiments is not 
limited to being implemented in a computer, but may 
be implemented a device that includes a CPU, such 
as a mobile terminal or home telephone. 

(7) The thread control unit shown in the embodi- & 
ments executes the threads in series by switching 
between threads at minute intervals. In other words, 

the thread control unit performs pseudo-parallel ex- 
ecution of the threads. However, the threads may 
actually be executed in parallel by a plurality of proc- so 
essor elements in a multiprocessor. 

(8) In the embodiments, objects generated by the 
object generation unit are assigned memory in the 
logical address space by the conventional OS mem- 

ory management mechanism in the same way asna- 55 
tivedata. However, special management maybe per- 
formed to assign memory to each object in a heap 
area that is one section in the logical address space. 



This special management may be realized by secur- 
ing the heap area according to a conventional OS 
memory management mechanism, allocating an un- 
allocated area in the heap area for generation of an 
object, and when an object is freed, setting the cor- 
responding area as an unused area. In this special 
management, it is necessary to further perform 
memory compaction in order to connect the seg- 
mented unallocated areas in the heap area. Note 
that for this reason, as shown in <3. Observations> 
this method of using a heap area is not necessarily 
the optimum method. 

(9) The GC system shown in the embodiments in- 
cludes a conventional OS memory management 
mechanism. However, an alternative is to provide 
the conventional OS memory management mecha- 
nism that manages memory using an MMU external 
to the GC system as a platform environment for the 
GC system. Here, the GC system secures and frees 
memory through the external memory management 
mechanism. 

(1 0) A program for having a CPU executing the var- 
ious processing (see FIG. 8 to FIG. 14, FIG. 17, and 
FIG. 1 8) for realizing the functions of the GC system 
shown in the embodiments may be distributed re- 
corded on a recording medium or via any of various 
types of communication paths. Examples of such a 
recording medium include an ICcard, an optical disc, 
a flexible disk, and a ROM. The distributed program 
may be put to use by being stored in a memory or 
the like that is readable by a CPU in a device that 
includes a CPU. The functions of the GC system 
shown in the embodiments are realized by CPU ex- 
ecuting the program. 

Industrial Applicability 

[01 62] The GC systemof the present invention may be 
used as an execution environment on a computer for APs 
(application programs) created in an object-oriented pro- 
gramming language, such as Java, that relieves the cre- 
ators of the APs from being concerned with allocation 
and freeing of memory area 



Claims 

1 . A garbage collection system that frees memory ar- 
eas corresponding to objects that are no longer re- 
quired in an execution procedure of an object-orient- 
ed program composed of a plurality of threads, the 
garbage collection system comprising: 

a selection unit operable to select the threads 
one at a time; 

an examination unit operable to execute exam- 
ination processing with respect to the selected 
thread, the examination processing including 
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procedures of stopping execution of the thread, 
finding an object that is accessible from the 
thread by referring to an object pointer, manag- 
ing the found object as a non-freeing target, and 
resuming execution of the thread; s 
a detection unit operable to, when having de- 
tected, after the selection unit has commenced 
selecting, that an object pointer has been proc- 
essed as a processing target by a currently-ex- 
ecuted thread, manage an object indicated by io 
the processing target object pointer, as a non- 
freeing target; and 

a freeing unit operable to, after the examination 
processing has been completed with respect to 
all of the threads, free memory areas that cor- is 
respond to objects other than the objects that 
are managed as non-freeing targets. 

2. The garbage collection system of Claim 1 , wherein 

the detection unit performs the detection onfy when 20 
the currently-executed thread has not yet been sub- 
ject to examination processing, and 
the detection unit includes: 

a finding sub-unit operable to, when having per- 25 
formed the detection, store, to a working mem- 
ory area that corresponds to the currently-exe- 
cuted thread, the processing target obj ect point- 
er and an object pointer in an object that can be 
reached from the processing target object point- 30 
er; and 

a management sub-unit operable to, while exe- 
cution of a thread is being stopped by the exam- 
ination unit, manage, as a non-freeing target, an 
object that can be reached from the object point- 35 
er in the working memory area corresponding 
to the thread. 

3. The garbage collection system of Claim 2, wherein 

the examination processing is processing for, when 40 
an object indicated by an obj ect pointer in a stack 
corresponding to the selected thread is found to be 
accessible, repeatedly performing a procedure of, 
only when both (a) the accessible object is not al- 
ready being managed as a non-freeing target and *s 
(b) an object pointer exists in the accessible object, 
further finding that an object indicated by the object 
pointer in the accessible object is accessible, 
the selection unit, after a first selection, further per- 
forms selection if, after the examination processing so 
has been performed by the examination unit, any 
threads out of the plurality of threads remain that 
have not been subject to the examination process- 
ing, and 

the selection unit refers to information about the 55 
threads, and makes the selection based one or more 
predetermined thread selection conditions. 



4. The garbage collection system of Claim 3, wherein 
the thread selection conditions include a condition 
indicating that any threads whose thread state is a 
wait state are to be selected before any threads 
whose thread state is a state other than the wait 
state, and 

if a thread whose thread state is the wait state exists 
when making the selection, the selection unit selects 
the thread whose state is the wait state. 

5. The garbage collection system of Claim 4, wherein 
the thread selection conditions include a condition 
indicating that any threads whose thread priority lev- 
el is low are to be selected before any threads whose 
thread priority level is high. 

6. The garbage collection system of Claim 5, wherein 
the thread selection conditions include a condition 
indicating that any threads whose corresponding 
stack size is small are to be selected before any 
threads whose corresponding stack size is large. 

7. The garbage collection system of Claim 6, further 
including a memory management mechanism that 
manages memory with use of a memory manage- 
ment unit (MMU), 

wherein each time an object is to be generated, a 
memory areacorresponding to the object is allocated 
by the memory management mechanism, and 
the freeing unit frees the memory areas via the mem- 
ory management mechanism. 

8. The garbage collection system of Claim 3, wherein 
the thread selection conditions include a condition 
indicating that any threads whose corresponding 
stack size is small are to be selected before any 
threads whose corresponding stack size is large. 

9. The garbage collection system of Claim 3, wherein 
the thread selection conditions include a condition 
indicating that any threads whose thread priority lev- 
el is low are to be selected before any threads whose 
thread priority level is high. 

10. The garbage collection system of Claim 1, using a 
memory management mechanism that manages 
memory with use of a memory management unit 
(MMU), 

wherein each time an object is to be generated, a 
memory area corresponding to the object is allocated 
by the memory management mechanism, and 
thefreeing unitfreesthe memory areas via the mem- 
ory management mechanism. 

11. A garbage collection method that, in a computer, 
frees memory areas corresponding to objects that 
are no longer required in an execution procedure of 
an object-oriented program composed of a plurality 
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of threads, the garbage collection method compris- 
ing: 

a selection step of selecting the threads one at 
a time; 5 
an examination step of executing examination 
processing with respect to the selected thread, 
the examination processing including proce- 
dures of stopping execution of the thread, finding 
an object that is accessible from the thread by "> 
referring to an object pointer, managing the 
found object as a non-freeing target, and resum- 
ing execution of the thread; 
a detection thread of, when having detected, af- 
ter the selection in the selection step has com- 1$ 
menced, that an object pointer has been proc- 
essed as a processing target by a currently-ex- 
ecuted thread, manage an object indicated by 
the processing target object pointer, as a non- 
freeing target; and 20 
a freeing step of, after the examination process - 
. ing has been completed with respect to all of the 
threads, freeing memory areas that correspond 
to objects other than the objects that are man- 
aged as non-freeing targets. 25 



ecuted thread, manage an object indicated by 
the processing target object pointer, as a non- 
freeing target; and 

a freeing step of, after the examination process- 
ing has been completed with respect to all of the 
threads, freeing memory areas that correspond 
to objects other than the objects that are man- 
aged as non-freeing targets. 

14. The garbage collection method of Claim 13, wherein 
the computer uses a memory management mecha- 
nism that manages memory with use of a memory 
management unit (MMU), and, in an execution pro- 
cedure of an object-oriented program, each time an 
object is to be generated, allocates a memory area 
corresponding to the object according to the memory 
management mechanism, and 
the freeing step frees the memory areas via the mem- 
ory management mechanism. 



12. The garbage collection method of Claim 1 1 , wherein 
the computer uses a memory management mecha- 
nism that manages memory with use of a memory 
management unit (MMU), and, in an execution pro- 30 
cedure of an object-oriented program, each time an 
object is to be generated, allocates a memory area 
corresponding to the object according to the memory 
management mechanism, and 
the freeing step frees the memory areas via the mem- 35 
ory management mechanism. 



1 3. A computer program for having a computer execute 
garbage collection processing that frees memory ar- 
eas corresponding to objects that are no longer re- *o 
quired in an execution procedure of an object-orient- 
ed program composed of a plurality of threads, the 
garbage collection processing including: 



a selection step of selecting the threads one at *s 
a time; 

an examination step of executing examination 
processing with respect to the selected thread, 
the examination processing including proce- 
dures of stopping execution of the thread, finding so 
an object that is accessible from the thread by 
referring to an object pointer, managing the 
found object as a non-freeing target, and resum- 
ing execution of the thread; 
a detection thread of, when having detected, af- 55 
ter the selection in the selection step has com- 
menced, that an object pointer has been proc- 
essed as a processing target by a currently-ex- 
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